home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20000217-20000824
/
000226_news@columbia.edu _Tue Apr 25 13:06:39 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2000-08-23
|
8KB
Return-Path: <news@columbia.edu>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA19114
for <kermit.misc@cpunix.cc.columbia.edu>; Tue, 25 Apr 2000 13:06:39 -0400 (EDT)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA28592
for <kermit.misc@watsun.cc.columbia.edu>; Tue, 25 Apr 2000 13:06:38 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id NAA16813
for kermit.misc@watsun.cc.columbia.edu; Tue, 25 Apr 2000 13:01:01 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: Ishikawa <ishikawa@yk.rim.or.jp>
Subject: Re: Parity incorrectly reported, and RTS/CTS problem on Solaris 7 for
Date: Wed, 26 Apr 2000 01:58:22 +0900
Organization: RIMNET InterNetNews site
Message-ID: <3905CEAE.ED82A8C6@yk.rim.or.jp>
To: kermit.misc@columbia.edu
Frank da Cruz wrote:
>
> : I can check 2.5.1 for sparc, 2.4 for x86 if necessary (and solaris 7 for
> : x86 as I explained above.)
> :
> OK, great; please send the results to kermit-support@columbia.edu, or post
> them if you think the general public will be interested; then we can
> adjust the makefile targets to do the appropriate thing for each Solaris
> version / hardware platform combination.
>
Attached is the memo I wrote after I tested C-kermit 7 on the
platforms. I am posting to the newsgroups since I think we need
volunteers to fill the gap. Kermit has been a great dependable tool
for me and would like to see it being so at least for the foreseeable
future and it is time to repay the debt, so to speak.
I am sure quite a f ew sun sysadmins use kermit for daily jobs.
>
> : I wonder MS has this kind of quick feedback from none other than the
> : one of the original authors of the software :-)
> :
> We try to take support seriously -- it makes the software better.
>
Again great thanks.
Happy Hacking,
Ishikawa
--- My test summary
(We need volunteers to figure out what we need to do for the other
Solaris versions for x86 and sparc that I could not test.)
In short, the summary of my test.
In order for kermit to enable hardware flow-control (RTS/CTS),
I needed to add -DPOSIX_CRTSCTS for the following platforms.
----------------------------------------
solaris 7 for x86 needs -DPOSIX_CRTSCTS
slaris 2.5.1 for sparc (on Ultra1 143Mhz) needs -DPOSIX_CRTSCTS
Another potential problem on this hardware platform.
split I/O speeds:
115200bps may not be supported on input. Output seems to
be OK. (I found this out from the stty output.)
solaris 2.4 for x86 needs -DPOSIX_CRTSCTS
----------------------------------------
It seems that the later solaris in my sampling needs -DPOSIX_CRTSCTS
for hardware rts/cts flow control to work. However, the debug log
message did pickup the failure of sysV rts/cts on routine (if I am not
mistaken) and so maybe a cleanup of the code could at least make it
possible to warn the user of the missing hardware flow-control support.
**** How I tested ****
for each target platform
do
I checked the setting of tty using
stty -a < /dev/my_choice_of_tty
before running kermit.
Run the compiled kermit (with / without -DPOSIX_CRTSCTS)
(from source
-rw-rw-r-- 1 ishikawa 2503931 Apr 25 21:58 cku197.tar.gz
)
log debug
(set the next tty target approrpriately)
set line /dev/tty00
set speed 115200
(needed to reduce speed on solaris 24 for x86)
set term byte 8
set parity hardware even
set flow-control rts/cts
connect
(May need to set set carrier-watch off before connect.)
After `connect', I re-checked the setting of tty using
stty -a < /dev/my_choice_of_tty
again, and see if crtscts is set or not.
check the output of
egrep tthflow debug.log
done
Details.
----------------------------------------
* Solaris 7 for x86: already reported. needs -DPOSIX_CRTSCTS
----------------------------------------
solaris 7 for x86: distributed binary
RTS/CTS doesn't work as reported previously.
log output.
$ grep tthflow debug.log
tthflow ATTSV RTS/CTS ON
tthflow TCGETX=-1
tthflow ATTSV RTS/CTS ON
tthflow TCGETX=-1
(Comment: it looks that the error code (x == -1) is
dropped through the safety net due to the
complex #ifdef/#else/#endif .. in ckutio.c, but I am not entirely
sure how to fix this.)
$
Recompiled with -DPOSIX_CRTSCTS (with suncc)
Now rts/cts works (verified using the file transfer in this
particular case as well as visual inspection of stty output.)
bash-2.03$ grep tthflow debug.log
tthflow POSIX_CRTSCTS entry status=1
tthflow POSIX_CRTSCTS tcgetattr[0]=0
tthflow POSIX_CRTSCTS ON tcsetattr[0]=0
tthflow POSIX_CRTSCTS entry status=1
tthflow POSIX_CRTSCTS tcgetattr[0]=0
tthflow POSIX_CRTSCTS entry status=1
tthflow POSIX_CRTSCTS tcgetattr[0]=0
========================================
* solaris 2.5.1 for sparc with gcc needs -DPOSIX_CRTSCTS
I noticed a split input/output speed on Ultra 1 143Mhz
CPU hardware platform. This can be a different annyoing problem.
----------------------------------------
(stty -a < /dev/ttya trick only works if I am root.)
The binary for the test was first created using
make solaris25g
egrep tthflow debug.log
tthflow ATTSV RTS/CTS ON
tthflow TCGETX=-1
Given the way the code works, maybe this version
is also buggy with regard to hardware flow-control.
Another possible problem: split I/O speeds!
In comparing the output of stty output before and after
kermit is invoked:
***************
*** 1,2 ****
! speed 9600 baud
--- 1,4 ----
! # stty -a < /dev/ttya
! ispeed 57600 baud <--- Aha! Maybe the input port
! ospeed 115200 baud only supports 57600?!
(On UltraSparc Ver 0x22 143MHz)
dmesg: root nexus = Sun Ultra 1 UPA/SBus (UltraSPARC 143MHz)
Recompiled adding -DPOSIX_CRTSCTS
make solaris25g-posix_crtscts
I confirmed that RTS/CTS is now enabled in stty output.
grep tthflow on
tthflow POSIX_CRTSCTS entry status=1
tthflow POSIX_CRTSCTS tcgetattr[0]=0
tthflow POSIX_CRTSCTS ON tcsetattr[0]=0
(However, the ttya connected to a printer or something
got confused, I guess. Minor quibble. Logistic problem.
No clean computer with my reach. Hope the printer is not
out of control now. I have forgotten essentially something was
connected on the port. )
A serial connection might still be active on /dev/ttya.
OK to exit? yes
Closing /dev/ttya...ttclos() timeout: hangup
========================================
solaris 2.4 for x86 with sun cc needs -DPOSIX_CRTSCTS
There is no 115200 bps on this old solaris.
(Well, at least not B115200 or B38400 in sgtty.h)
So tested at 19200 bps.
----------------------------------------
There was no entry for suncc on sun2.4 so I used solaris2x
make solaris2x
: www:/tmp/ ; grep tthflow debug.log
tthflow ATTSV RTS/CTS ON
tthflow TCGETX=-1
tthflow ATTSV RTS/CTS ON
tthflow TCGETX=-1
: www:/tmp/ ;
RTS/CTS not set from what I saw in "stty -a < /dev/ttya".
Re-created by adding -DPOSIX_CRTSCTS.
Now confirmed that RTS/CTS is enabled in stty output.
grep tthflow debug.log
tthflow POSIX_CRTSCTS entry status=1
tthflow POSIX_CRTSCTS tcgetattr[0]=0
tthflow POSIX_CRTSCTS ON tcsetattr[0]=0
tthflow POSIX_CRTSCTS entry status=1
tthflow POSIX_CRTSCTS tcgetattr[0]=0
: www:/tmp/ ;
[end of file]